Skip to content

Add new setting keepFilename that retains the original filename #2

Open
jonspalmer wants to merge 1 commit into
Grailsrocks:masterfrom
jonspalmer:keepFilename
Open

Add new setting keepFilename that retains the original filename #2
jonspalmer wants to merge 1 commit into
Grailsrocks:masterfrom
jonspalmer:keepFilename

Conversation

@jonspalmer

Copy link
Copy Markdown

If keepFilename is true then the original filename is retained with the unique hash appended to it prior to the extension.

In production environment I don't want to completely obfuscate the filenames of the css and js as it makes debugging incredibly difficult. Having the option to retain the original filename allows simple debugging of which files are being loaded etc. while still giving all the benefit of caching resources that don't change in content.

…ust appends the hashed id before the extension.
@andrew-wharton

Copy link
Copy Markdown

:-) didn't notice this pull request and implemented pretty much the exact same feature.

I think that this means that enough people want this feature to be included that it should be added. It does not matter to me which we use, as long as it gets pulled in.

@tednaleid

Copy link
Copy Markdown

There's also open JIRA ticket for this with a few more patches :)

http://jira.grails.org/browse/GPCACHEDRESOURCES-3

@divideby0

Copy link
Copy Markdown

Bump. Are there any plans to merge this?

@jamesdh

jamesdh commented Nov 19, 2012

Copy link
Copy Markdown

Yes. This plugin needs this badly. Please merge!

@ScottIngram

Copy link
Copy Markdown

This feature is critical to our project. I just merged the patch into my local copy, but of course that will be clobbered when we launch to production. I suppose I could simply fork your plugin and abandon the original. Great plugin, otherwise.

@tednaleid

Copy link
Copy Markdown

That's what I've done on the last few projects, just forked locally and used it as a local plugin just to get this patch in.

Looking forward to switching over to the asset-pipeline plugin as the entire resources infrastructure has pretty much been left for dead.

Appreciate the work that was put into all of this originally, but control really needs to be transferred if none of the current committers are willing to do even basic maintenance.

@divideby0

Copy link
Copy Markdown

Our progression over the last year has been from resources -> asset pipeline -> dedicated grunt build. It's not for everyone but once you get over the initial hurdles of setting up node/npm, I've found grunt to be a much more traveled path for these sorts of things.

@tednaleid

Copy link
Copy Markdown

@divideby0 agreed. Grunt with require.js is a great combination that I used on my last project. Current project has a bunch of existing code to maintain so we can't go there (yet), but for greenfield projects that's a really good choice IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants